: Use this option to add a new request manually. An input form will be displayed consisting of multiple tabs. The sections of the form are
· General Data related to the internal processing of the request
· Bibliographic Bibliographic data for the request
· Request Source Original request details
· Additional Any additional information entered with the request
· Client ` Borrower information
· Supplier Specific information about supplying library
· Delivery Delivery information
· Charging Information on related charges
Precise details of what is ON the form depend on the type of request and how far is has been processed through its life-cycle.
The example below is of an existing request.
Title: For display only, the title of the work requested. If a specific "full" bibliographic record has been identified, the title will be taken from this; otherwise this is as received or entered by staff or borrower.
Request status: For display only, the current overall status of the request. See section 821.7 for a list of possible statuses.
Alerts: This shows the latest response (previously unnotified) – for example "Message : 14 Sep 2006". If there is more than one such response, then the display "Various : 12 Sep 2006 – 14 Sep 2006" is shown.
You can use the button to look at details of alerts.
Request Number: This is a system assigned sequence number, based on the format defined for the department in AFO 822.
Request date: For new requests entered manually, it defaults to "today", of course, but may be amended. For WebOpac requests it is taken from the date the request was submitted. It should be noted that the system also records the date entered.
Required by: Optional date by which the request is required. This MAY be edited for WebOpac requests before dispatch of the request.
Expiry date: Optional field with expiry date of the request. If the expiry date is set, then the system will generate an “Expiry” message. This will be sent using the ISOILL mechanism (when that is the mechanism used to communicate the request) or, if a notice layout has been defined for the requesting library's notice set, then an expiry letter will be created (for subsequent printing or email).
The request must have a status of “Pending”, “Inprocess” or “Conditions” for this to apply; once the item has been supplied then obviously the expiry date no longer applies.
Staff notes: These are meant for "local" use. They may therefore be updated at any time.
Placed: This display line shows information about the request. The command button allows for the display of full details.
Source of request: For incoming requests, this allows the library to record, for informational purposes, how the request was received.
Internal system record id: The internal record number of the request (displayed for use by Infor support).
Current protocol: Whether manual or automated – note that this is a function of the requesting/supplying library mostly.
For an outgoing request, this display initially may be empty. Typically however it is expected that staff would use Z3950 searching etc, to retrieve a better description than that received on paper or via the WebOpac.
In this case, the record displayed will reflect the record selected from some remote source. The data displayed is not, of course, taken in real time from the remote system. During the process of selection, the "best" record found is loaded into the Request database and it is this that is displayed.
In order to clarify this, it should be noted that the request therefore has typically links to TWO bibliographic records – the one in the Request database which holds the original source data, and the second being the selected remote record.
When the actual requested item is received by the library (for loans not non-returnable copies) then the system automatically creates a suitable "dummy" item record (which may be used for the actual loan to the borrower). This dummy item, and its current status (e.g. on loan) are also displayed on this screen.
The "Request source" section of the form displays the bibliographic details as originally received.
For requests which are to be entered manually by staff – that is, for outgoing requests for which the request is received on "paper", then this data may be added (and subsequently updated) at any time. Whether staff choose to enter such data is simply a matter of policy i.e. it is optional. The data entered here is meant to represent the request in its original form.
For outgoing requests, it is possible for staff to make remote searches either to find a better bibliographic description or to find a library from whom the request can be made (or both). The data present on the "source" screen is used to create a default search but it is not required.
This tab is used for less commonly used fields, particularly for specific types of control number. There are three “user defined” fields available here – shown as “Additional number A, b and c” but the specific wording can be changed from AFO 822 – General options – General system settings.
The “Unstructured text” field is typically used for outgoing requests entered by borrowers. There is an option in the WebOpac Preferencesto allow this field to be offered. The intention is to allow requesters to, perhaps, find details from a Web site and to paste these into this free form text field, rather than identify “Title, author” and so on individually. Its use is completely optional.
This section allows for the display and modification of the borrower details.
For outgoing requests, the screen is as shown and may be entered as necessary by staff. For WebOpac requests, the user details are, of course, determined from the request; in this latter case, they may still be updated by staff.
For a new request, the borrower is selected by using the button on the form , which takes you to the regular borrower search display, and from which the requester may be selected. If the borrower/client is already assigned, then the button takes you straight to the borrower record. It is possible at the early stages of the request to change the borrower – in which case, the button next to the client id field must be used first.
Client id : The client id field itself is protected. The button is used to select from the borrower database (as described above).
Name: This is always protected when derived from the selected borrower record. If no current borrower is selected, then name and address (below) may be keyed manually.
System status: This is the status of the borrower (Incomplete, Complete, Blocked, etc.).
Quota: Displays the current quota allocation for the borrower when such quotas are used. Where quotas are in use, this defaults to 1. For certain requests, staff may choose to "use up" more than 1 unit of the quota. This is an optional field (not shown in the example above).
Status in request: Allows a status (as per ISOILL protocol) to be assigned to a client, when the details are to be sent with the request. Currently only Good and Bad are supported.
Max. price (local currency): Is the maximum the client is prepared to pay for request.
Charge to client/budget: A client charge is calculated according to the type of request. It may be overridden by explicitly setting this field.
Budget code: The budget to which the amount payable should be charged. You can use the button to select a budget as defined (in AFO 431) for this particular borrower.
Client will pay full request charge: This is mainly for information purposes, indicating that the full cost of the request to the library will be passed on to the client.
Since, in general, the cost may not be known until an invoice is received from the supplier, this has the effect of preventing the lending charges being entered, or made payable.
When the final charge IS known, then this setting should be cleared; the charge to the client can then be entered manually on the Lending charges screen, and made payable.
Use in library only: This is a specific requirement for the item when received. It may also be set as a condition from the supplying library, but even if not explicitly requested by the supplier, it can also be set "locally".
Special item category: By default, the system will assign an item type for ILL loans. This can be overridden for this specific item.
Send client information: Indicates whether client details should be included with the request.
Output method: Defines the output method for "correspondence" with the user. This might, for example, be configured to use email if available, otherwise the address defined.
Address: This is the address to be used for correspondence, and for delivery of the item when Send direct is in use. The button allows you to select from the user addresses defined for the borrower, but this may be updated from this screen.
Pickup location: The pickup location defaults to the ILL Department when entering a request manually, but it need not be so (for example, it might be policy for circulation staff to simply hold the item at the main reservation desk, and leave ILL staff to go and collect the item, when notified according to the "message by" settings.
For WebOpac requests, the library can allow users to select a pickup location.
Printed copy requested: Clients can indicate whether they prefer a printed copy. Note that this doesn't mean that this is what they will get – simply that they are offered a choice to request it.
Optional fields: These are “yes/no” optional fields which can be defined for use in AFO 822.
The Supplier tab details the library where the item is to be found.
Supplier symbol: Specifies the code for the required supplier. This may be entered directly OR it can be looked up with the button.
Service type: Whether the request is for a loan or a copy.
Service level: Whether normal / rush etc (as defined under Search / Service levels).
Item type: Whether monographic, serial, thesis or other.
Preferred medium: An optional field.
Alternative edition: To indicate if an alternative is acceptable.
Reference: Additional information for non-ISOILL requests.
Search level: Additional level of service information.
Copyright Compliance: A code to indicate copyright regulations or laws to which the requester is adhering. Standard codes are usually used.
Other instructions: Other explicit instructions.
These two are defined for the supplying library. Typically in use for the British Library, for example.
Place on hold: Can be used to indicate whether we would like the supplying library to place a reservation if no copy immediately available.
Max price (local currency): A maximum the requester is willing to pay (in OUR currency).
Reciprocal agreement, Will pay fee, Payment provided: Check boxes to indicate these conditions apply.
Account: The library's account number with the supplier. This is populated automatically when the supplier is selected, but may be manually amended thereafter.
Note to supplier: A note to be included in the request transmitted
Additional charges: This is populated when specific “other instructions” are chosen, as a reminder that this may be the case.
The delivery tab details how the item is actually going to be delivered.
Item delivery: Electronic or physical delivery may be specified.
Physical delivery method: Depending on the item delivery field, one or other of these actual delivery methods may be selected.
Delivery address: Determines the actual address to which the item is to be shipped. For electronic delivery, this is the appropriate IP address or email address etc, pertinent to the Electronic delivery method.
The button allows staff to select an appropriate address from the supplying library's setup, or an electronic address relevant to the delivery method.
For incoming ISOILL requests, these may be supplied.
Electronic delivery method: For ISOILL incoming requests this will be completed from the incoming request, if supplied. Otherwise, an electronic delivery method for the requester (i.e. either the library or the remote requesting library) may be selected by using the button.
Send direct: For suppliers for which this is valid, this can be selected allow the item to be sent directly to the borrower.
Borrower delivery address: When the previous option is checked, you can use the button to select an address as defined for the borrower to which the material will be sent directly.
Further shipping information: This allows for further information about the dispatch of the item. These fields may be "prepared" in advance, but any data entered here is displayed at the time that the item is actually shipped, and may be added or changed at the time of shipment.
The button can be used to add or change a Condition. A dropdown list with valid codes will be displayed.
Renewable: To indicate whether a supplied item may be renewed.
Due date: This is calculated according to the regular loan rules, or is taken explicitly from the due date entered here (and may be changed on confirmation of the loan).
Shipping note: An optional free text field.
This section allows staff to display maintain details about the charges applied to the loan.
Charge to library: the initial charges calculated based on the charge scheme applicable to the supplying library. The button can be used to change these, see section 821.6.7.
Chargeable units: Typically used for copies – the number of pages.
Payment method: Optionally select a payment method from the dropdown list.
Payment reference: Optionally add reference information as free text.
Invoice number: This may be manually amended for outgoing requests i.e. if the library wishes to record a supplier's invoice number against the request.
Insured for, Return insurance, Currency: Optionally you can add amounts for insurance for sending and returning of the item, in a particular currency.
Billing address: For manually entered requests you can use the button to select a defined address for the supplying library.
Borrower invoice address: When the material will be sent directly to the borrower (see under Tab Client), you can use the button to select a billing address as defined for the borrower to which the invoice can be sent.
: Select a status line and then this option to view the requests with this status. An overview screen will be displayed:
: This option is not valid here.
: Select a line and then this option to display the details of a request. See section 821.4.1 for a description of all tabs on this form.
: This option allows the user to search for a specific set of requests. After choosing this option, a selection form is displayed:
Select the required criterion and click , the system takes you the screen nearest to the searched for library.
: This option allows specific searches to be made against the requests database. After selecting this option the standard screen for bibliographic searches will be displayed.
Notes
The bibliographic data for outgoing requests is held in a separate database, installed by the installation options described previously, together with its own indexes. However, in a transient way, it is possible to link an outgoing request to a record in the system's main database(s) – in the situation that a borrower has failed to recognize that the library has a copy of the requested title.
Incoming requests will be stored in the special request database AND, when the match between the request and the local databases has been made, then they will also be indexed against records in the main database.
A search from this AFO will always apply a special filter – i.e. it will only retrieve matches for which there IS an interlibrary loan request.
Having found a suitable bibliographic record, the user must select the “” option from the full display, which will then lead to a summary display of the requests attached to this title:
: This option allows specific searches to be made against the requests database.
A special search form appears:
Search term: is the expression to be used for the search. The button can be used to select a particular library (as defined in AFO 822 – ILL Libraries).
Search type: offers a dropdown list of various types. See below for the differences.
The following fields allow the search to be further qualified.
Request status: offers a dropdown list of possible requests statuses. See section 821.7 for a list of possible statuses.
Incoming / Outgoing requests: These two settings allow the user to limit the search to the specified type of request.
Dates: This set of four fields allows the user to define a date range – based on a specific type of date from the request.
Limit search to current transactions: The searching may get rather complex ,since a single request may have multiple transactions (i.e. it has been sent to library A, then forwarded to B and so on).
This option tells the system whether to look only at the latest such transaction or whether to check through the “history” of the request. If not checked, for example, then a search on “Not supplied date” would find a request which might be “supplied” but which was “not supplied” at some point in its lifecycle. (Clearly some selections imply the latest transaction e.g. Supplied date).
By borrower
The search term for a borrower may be either the borrower barcode number or a name. If this is selected then this behaves as a regular borrower search, and either a unique match or a list of matching borrowers is returned.
When a specific borrower is selected, the system will effectively return the borrower record, from which the list of requests for that borrower may be selected.
On the assumption that any one borrower has a relatively small number of requests at any one time, the additional filters are NOT relevant at this point.
To all intents and purposes, this search is the same as going to AFO431, finding a borrower and listing their ILL requests. The key point is that it saves effort in swapping backwards and forwards between AFO's.
The borrower search list will display the number of ILL requests when the search is initiated from this route, so that when there are multiple matches, the system shows at a glance, which borrowers DO have requests.
This search does NOT search for the borrower name and id attached to incoming requests. There is little value in allowing for a search on the borrower on someone else's system!
By request id and library
Searching by library allows for the searching by the name of a defined library OR by their code. Searching by name implies a right truncation (thus "Trinity" would find "
Searching by request id also implies right truncation – thus "RLG" would find "RLG001", "RLG002" etc.
In either case, if the result generates multiple matches, then a summary listing will be displayed from which the user may selected a specific request.
The action and events command button on request forms is used to drive the request through its lifecycle.
The actions or events which may be selected depend on the current state of the request, whether it is an incoming or outgoing request and also on whether it is a manually entered.
A typical pop-up offered using the button might look like
Selection of a specific action will usually result in a subsequent set of options being offered (sometimes trivial – for example, a "are you really sure you wish to cancel this request" type message).
Actions are offered with what are the most common options at the top. It should also be noted that the user does not have to work through the "logical" steps (for example, it is not necessary to send a "Will supply" reply before supplying the item). Only actions which are relevant to the current request are offered.
The results of specific actions are shown below.
For responses that are "outgoing", most forms have a "Send now" option. This applies only to manually processed requests. Usually outputs are processed in bulk, but the "Send now" causes the system to send the appropriate letter or email at once.
Note
Although the command to "forward" a request could be considered an "action", there are a number of facets to this, which may require amendment to the request as a whole. This is therefore handled by the "forward" option rather an action/event (see chapter 6 for an explanation of this command). Actions/events may therefore be thought of as mainly things to do with the dealings with a specific responder library rather than the request as a whole.
Alerts
In addition to such manually initiated actions or events, incoming responses may require (or at least, expect) the library to respond. Such responses may be initiated via the Action command, or may be initiated from the Alerts processing for an individual request.
Below is an explanation of different situations in which a cancellation action can be performed.
If a supplier has been selected and the request sent, then the request cannot just be cancelled – a cancellation message must be sent to the supplier. However, if no supplier has been selected, then the cancellation is interpreted as meaning, effectively, delete the request.
A warning message is popped up …
And then the following form is offered
The note displayed is automatically taken from the cancellation reason shown, but may be amended or deleted manually.
Depending on the reason for cancelling the request, then it may or may not be appropriate to send a notice to the borrower. In common with all such actions, it is possible to print the notice immediately or save them up as “deferred prints” for printing in batch later on.
In this case, there are two considerations – firstly, we must request the supplier to cancel the request – so a reply is required; secondly, we may want to cancel the request completely OR we may just be cancelling it for this supplier, and we subsequently wish to forward the request to another supplier.
The cancellation is made up of 3 parts – the first to indicate the cancellation reason (as before) but also whether we want to physically send the cancellation.
It is also possible to simply record the fact that the borrower wants to cancel the request – as opposed to the library actually asking for it to be cancelled.
The second section, as before, tells the system whether a notice should be sent to the borrower to tell them that we intend to cancel it. (Note that this does not necessarily mean that the request IS cancelled).
This distinction can be made in the notices available – see lines 1, 6 or 7 above.
The third section tells the system what to do when the cancellation is confirmed. It warns the user whether other forwarding libraries have been entered, and then what to do to the request. It may be automatically deleted, reset to pending for the next library – or reset to pending, awaiting instructions as to what to do next.
Here is the third section when a forwarding library has been entered.
For ISOILL requests, these will be delivered by the ISOILL processing automatically.
The setting on the cancellation “Automatically delete the request on receipt of reply” causes the request to be fully cancelled if a positive reply is received.
If this setting is NOT checked, then the request is returned to the Pending state, waiting perhaps to be forwarded to another library.
It will appear in the pending list as follows
In this case, if the request is selected, then the CANCEL action is taken to mean that the library now wishes to fully cancel the request.
The following message is displayed
If the request IS fully cancelled by using the button, then a subsequent option is offered
This offers the library the chance to inform the borrower that the request is cancelled.
This represents a wish by the requesting library that the request be cancelled.
The cancellation request will be received and processed automatically for ISOILL requests; otherwise, for manual requests:
For ISOILL requests, a cancellation is a two step process – the submission by requesting library that they want to cancel; followed by a Yes or No response from the supplying library.
For manually entered requests, this sequence is reproduced "logically" but can be entered in a single input as above. It is possible to record the cancellation request and set " reply later" to mimic the ISOILL protocol but it seems unlikely that anyone would go to this trouble. In ISOILL it is necessary (and done automatically, of course) to acknowledge the cancellation; manually this may not be necessary and the "Accept cancellation" option DOES that without a reply.
From this screen, the user may therefore enter the cancellation request AND reply to this in one operation. They may choose to “log” the cancellation request but to decide later on – in which case the “Cancel reply” action can be used.
Depending on the result, the status of the request changes
In this example, we simply logged the cancellation request. An Alert is generated automatically to remind us that we DO need to reply at some point.
This is a confirmation of the cancellation; if, for example, the item has already been shipped or too late to prevent this, it is possible to say "No" to the cancellation.
This is required for ISOILL transactions, and is optional otherwise. It might be used at a subsequent stage, when the "No need to send a confirmation" option was selected above.
Remembering that this is a reply to us – so there is nothing to communicate to the replying library…
If the cancellation is accepted, then the next step is
And then finally, do we want to confirm to the borrower that the request was cancelled.
Below is an explanation of different situations in which a reply action can be performed.
Replies are a standard set of possible responses to a request. A conditional reply is handled by a separate action command.
Type of reply: Comes up with a default entry. You can use the button to select a reply code as defined in AFO 822 – Miscellaneous parameters settings – Reply codes.
Explanation: A dropdown list of possible explanations, determined according to the type of reply. This further refines the reason for the type of message – and depends on that message.
Note: A note field for further clarification.
Hold placed - medium type: For the “hold placed” reply. May be sent on its own, but note that this reply is also automatically generated if a reservation is really placed on the requested title.
Estimated supply date: May be entered, and is relevant for the “hold placed” and “will supply” responses.
Refer to library: This must be entered for a “Locations” message. This is basically a suggested referral to another location.
Send immediately: As standardly used (i.e. to send a printed reply at once, for non ISOILL requests).
Replies to a request for cancellation are handled by a separate action, as are renewal replies.
These are all standard messages as implied by the ISOILL protocol. Additional explanations may be added to the system in AFO 822.
For ISOILL requests, the Reply will of course come from the supplying library. For non ISOILL requests, then this method is used to record the reply from the supplying library. It has the same interface as for incoming requests; the "send now" option is suppressed of course, since this is a response from the supplying library.
If the reply corresponds to an inability of the supplying library to supply the required item, then staff are prompted to either forward the request or to delete it.
Messages are used to send free text information.
As can be seen above, it is almost always possible to send a message about a request, or to log a message from the supplying (or requesting) library.
The command button can also be used to send a message to a supplying library
These lead to the input forms below.
The first is for the email option and has a Subject line.
In both cases, the full information about the request is available for display on the printed/emailed output. However, the former route (via Action) is meant to be used to send a specific message about the request (and the layout is defined in the Library notice set), whereas the latter is there for more general messages (e.g. “what is your phone number?”) and the layout is defined for the department notice set.
It is also possible to send a general message to a borrower:
This records the supply to a requesting library of a real item for loan.
The first step requires the entering of the item barcode:
This is followed by the selection of specific details. This depends on whether it is a loan item or a copy.
The input form is made up of two parts – the details of the supply, and then an “Addresses” tab to assign the specific details for the delivery of the item.
The button can be used to assign the details of the charges related to the supply of this item- these may have been setup before the supply of the item. See section on charges for more details.
Supply date: Defaults to today.
Due date: Calculated using item/borrower matrix, or taken from explicit setting in Delivery tab but may be amended here.
Renewable: To indicate whether a supplied item may be renewed. Information may be taken from Delivery tab.
Shipping note: An optional free text field. Information may be taken from Delivery tab.
Conditions: Information taken from Delivery tab. A dropdown list with valid codes is displayed if you wish to change this.
The Charges related fields are taken from the Charges tab of the request – which may be amended at point of supply.
Copy sent in electronic form: Check this box to denote an electronic copy will be supplied.
Electronic copy location: If this is an electronic copy, it is possible to enter the physical address of the file. This can then be made available to the user in the WebOpac.
Send "supplied notice": Possibly later or immediately.
Note on delayed supply message
There is no provision in the ISOILL protocol for cancelling a request once a loan item has been shipped. In practice, of course, it is unlikely that this "supplied" message is entered at the precise moment that a package is given to the postman; it is possible therefore to enter a few hours delay between entering the "supplied" action and the "supplied" message being sent to the requesting library. This gives a grace period in which it is then formally possible to still cancel the request, and undo the "supplied" setting.
If this is an ISOILL request, then the Delivery information is protected.
Delivery address: Determines the actual address to which the item is to be shipped. For electronic delivery, this is the appropriate IP address or email address etc, pertinent to the Electronic delivery method.
The button allows staff to select an appropriate address from the requesting library's setup, or an electronic address relevant to the delivery method.
For incoming ISOILL requests, these may be supplied.
Physical delivery method: Depending on the item delivery field, one of these actual delivery methods may be selected.
Item labels, Mailing labels: Specific sets of labels may be selected from the dropdown lists, appropriate to the packaging required for the delivery.
Return address: Determines the actual address to which the item can be returned. With the button you can select an appropriate address from your ILL departments.
For incoming ISOILL requests, these may be supplied.
This is a more or less mandatory screen – required to record the actual receipt of the supplied item or copy.
Date received: Defaults to today.
Date due: Calculated using item/borrower matrix, or taken from explicit setting in Delivery tab but may be amended here.
Note: Optional free text field.
Send receipt acknowledgement: Select the required option for sending a message to the supplying library confirming receipt of the item.
Send immediately: If you have selected to inform the supplying library in the previous option, you can check this option to generate the message immediately (for non ISOILL requests).
Service type: To denote whether this is a Loan or a Copy.
Copy sent in electronic form: Check this box to denote an electronic copy has been supplied.
Item category: The item category is assigned according to the default for the Department setting, unless explicitly set in the request Client/Special item category field.
System generated barcode: Apart from updating the
Barcode on supplied item: May be entered and used subsequently. It may be an actual barcode stuck in the supplied item, but it could equally well be the UPC/EAN barcode. It may be used to actually issue the item to the borrower on the local system.
Loan note: May be optionally entered (free text), to be displayed when the item is issued to the client.
Print insert slip: Option to print an insert slip (only available if defined in the notice set for the department).
Print insert slip now: If you have selected the previous option, you can check this option to generate the slip immediately (otherwise it can be printed later).
Item labels: Option to print an item label (only available if defined in the notice set for the department).
Pickup location: If the pickup location is different from the current (ILL department, presumably), then an option to put the item into transit is offered instead.
This may be used for the receipt of an item (for an outgoing request). For an item sent by the local library, this can be used to record the fact of and date of receipt at the requesting library (otherwise typically supported by ISOILL).
Make request available: When this option is checked, it tells the system to inform the borrower.
Electronic copy location: If this is an electronic copy, it is possible to enter the physical address of the file. This can then be made available to the user in the WebOpac.
The receipt of an item supplied by the library is automatically logged using the ISOILL protocol. It is currently NOT possible to log this manually – though one doubts whether too many libraries would bother with this, anyway.
This is used to record the return of an item back to the supplier.
Return date: Defaults to today.
Return via service: is a field in the ISOILL protocol which isn't clearly defined but something may be entered here.
Return insurance: Currency: Amount and currency for insurance fee when returning the item. Defaults from the Charging tab, but may be amended here.
Note: Optional free text field.
Return address: Determines the actual address to which the item can be returned. With the button you can select an appropriate address from your ILL departments. May contain the address entered on receipt of the item (see above).
For incoming ISOILL requests, these may be supplied.
Mailing labels: Option to print a mailing label (only available if defined in the notice set for the department).
Print labels now: If you have selected the previous option, you can check this option to print the labels immediately (otherwise they will be deferred for later printing).
Send return notice: Check this box for sending a message to inform the supplying library you are returning the item.
Send immediately: If you have selected to inform the supplying library in the previous option, you can check this option to generate the message immediately (for non ISOILL requests).
The fact that an item is being returned is logged automatically when using ISOILL. This information may be logged here. But it is unlikely that many libraries would want to do this manually.
The Check-in action is used to record the fact that a loaned item has been received back from the requester.
This straightforward input forms allows for the recording of the check-in.
Before this action, the ILL item may also have been returned in the normal way via AFO 412.
For ISOILL libraries, which can receive such messages, a message to this effect is automatically sent. If required, this can be recorded on outgoing requests i.e. that the supplying library has received the item back from the current ILL department, BUT this is not mandatory and the request is considered to be "complete" without this information being logged. In other words, for manual libraries, the fact of recording the return of the item is sufficient to make the request "historic".
Below is a description of renewals in various circumstances.
This action is used to request the renewal of an existing (currently received) loan.
You can enter the new Desired due date and optionally add a Note.
Send immediately: There is no option not to send the renewal request, but you can check this option to generate the message immediately (for non ISOILL requests).
For incoming requests, this can be used to record the fact of the renewal request. However, this is not absolutely necessary – if the renewal is refused, then there may be no need to enter it; if it is accepted, then the renewal acceptance screen (q.v.) implies a renewal request, of course.
This is used to send a response and record the fact of renewal. If a renewal request had previously been entered then the "Desired due date" field is displayed, and the Actual due date defaults to that date; otherwise both of these fields will be blank.
For ISOLL requests, the "send" information is ignored and the renewal (yes or no) will be sent. For manual requests, it is possible to skip sending the response, since this may have been communicated in some other way (e.g. a phone call!).
For outgoing requests, this can be recorded.
If the local borrower requested a renewal via the WebOpac, then the following option is offered.
That is: just because the supplying library renewed the loan, then it is not necessarily true that the loan to the borrower is renewed. The converse is also true however, so it is possible to renew the loan even though the library's renewal was refused.
Note
In all cases, it is never possible to renew an ILL request other than from the ILL module.
Below is a description of various item related actions / events.
Either the supplier or the requesting library may record the fact of an item being lost. This effectively terminates the transaction, but as far as the requesting library, this may not, of course, be the end of the whole request (since it may be forwarded to another library).
Mark the appropriate option for Lost by and optionally add a Note. You can add a Missing status (as defined in AFO 481 – Loan status code settings for your own library).
Send notice: Check this box for sending a message to inform the supplying library.
Send immediately: If you have selected to inform the supplying library in the previous option, you can check this option to generate the message immediately (for non ISOILL requests).
Mark the appropriate option for Damaged by and optionally add a Note. You can specify the Damaged portion.
Send notice: Check this box for sending a message to inform the supplying library.
Send immediately: If you have selected to inform the supplying library in the previous option, you can check this option to generate the message immediately (for non ISOILL requests).
This is used to request that a loaned item is returned immediately.
As for most of these actions, this is valid for an incoming request (i.e. a loaned item), OR for a manually processed outgoing request (to be able to log the fact of the recall against the request).
If the loaned item is NOT on loan to the local borrower, then this form is shown.
If the item is on loan then this form is offered to allow staff to send a recall to the actual client (borrower) who has the item.
Below is a description of various actions / events related to special conditions.
This action allows a conditional answer to be sent back to the requester.
Select a Condition from the dropdown list (corresponding to the ISOILL protocol) and set a Reply by date. Optionally add a Note.
If this is a manually maintained request, an option to Send reply immediately is offered (otherwise the condition will appear in the Deferred prints display).
Note
Multiple conditions may be set in the “body” of the request- so the “Set condition” command takes these one by one from those defined in the body.
For ISOILL outgoing requests, this information is, of course, returned by the supplying library, but for manual outgoing requests, this may be manually entered, if required, to record the conditions applied.
So for outgoing requests, the system offers the user a chance to record the condition AND to reply to it at the same time.
Select a Condition from the dropdown list (corresponding to the ISOILL protocol) and set a Reply by date. Optionally add a Note.
Indicate whether you Accept conditions and optionally add a Note.
If this is a manually maintained request, an option to Send reply immediately is offered (otherwise the condition will appear in the Deferred prints display).
The Condition reply action allows the user to respond to an outstanding conditional answer.
Any conditional responses received for an outgoing request are treated as "Alerts" until they have been responded to. Responses may also be initiated from the Alerts or history display for the condition.
Indicate whether you Accept conditions and optionally add a Note.
If this is a manually maintained request, an option to Send reply immediately is offered (otherwise the condition will appear in the Deferred prints display).
This section summarises the functions of the command buttons. The actions of these are defined in detail in separate sections below.
Unlike the command buttons attached to individual fields, these command typically apply to the request as a whole. In particular, use of these buttons causes the system to save the request as edited; prior to any use of these buttons any changes may be "undone" by using the button.
: This is the key command for the request. It allows staff to initiate or record an event or an action for the request. The action command offers activities relevant to the current state of the request. For example, to record the supply of an item, the Action/Event button offers a "Supply" option. See chapter 821.5 (above) for full details.
: For incoming requests displays the records on the local system which may have been automatically matched to the request, and allows staff to select or search further for a matching record on the database. See section 821.6.1 for full details.
: For outgoing requests allows staff to search remote systems for possible appropriate records. See section 821.6.2 for full details.
: Allows staff to place a reservation for the selected title. See section 821.6.3 for full details.
: This allows “control” of the request to be transferred to another ILL department. See section 821.6.4 for full details.
: Takes staff to the screens for maintaining libraries to which requests might be forwarded. See section 821.6.5 for full details.
: allows staff to change the ILL request to an order or a regular reservation. See section 821.6.6 for full details.
: Takes staff to the "complex" charges maintenance screens. See section 821.6.7 for full details.
: Causes a display of the states and events during the life of the request. See section 821.6.8 for full details.
: Is used to actually SEND the request. Dependent on whether this is to an ISOILL library, a dialogue is opened regarding printing and so on. (This is really an Action/Event as well, but is a shorthand command to get to this action). See section 821.6.9 for full details.
: This is a short cut to take the user to the library maintenance screens. See section 821.6.10 for full details.
: This lets you search for a client for the request if not entered. See section 821.6.11 for full details.
: Simply saves the changes to the request, without moving it "on" through its lifecycle, but note comment under Send command.
: Cancels any manual changes to the request.
Note
Which command buttons are actually available on a form depends on the type (incoming or outgoing) and status (In process, On loan, Conditional, etc.) of the request.
: For incoming requests displays the records on the local system which may have been automatically matched to the request, and allows staff to select or search further for a matching record on the database.
How the local database should be searched is defined from AFO 822 - General options - Automatic searching.
Depending on the situation, the system may display various messages:
If there are no matches, the system will display an empty result screen:
You can now use the option , which will bring up the standard bibliographic search form, to try and find an appropriate record in a different way.
See below for a description of the other options on this screen and subsequent screens.
If there are matches, the system will display the results:
: This will bring up the standard bibliographic search form, to try and find an appropriate record in a different way.
: Select a line and then this option to retrieve the record. The technical overview screen will be displayed. Having found a suitable bibliographic record, the user must select the “” option from the full display, after which the system will return to the request form. The details of the retrieved record are now stored on Tab Bibliographic.
: Select a line and then this option to view the bibliographic description in read-only mode.
: For outgoing requests allows staff to search remote systems for possible appropriate records.
For an outgoing request, the system allows the ILL staff to make enquiries on external systems using Z3950 search and retrieval. There are two contexts in which this is relevant.
Firstly, the request may have been submitted on paper, or via the WebOpac with very brief (and possibly incorrect) bibliographic details. The remote searching will allow staff to search for the record in order to update and enhance the bibliographic data associated with the request (before sending it to the selected library or libraries).
In addition, the same function can also be used to select the library (or libraries) to which the request is to be sent – that is, it can be used to search the possible libraries from which it is to be requested to see if they have an appropriate copy of the work.
The system will attempt to select the most appropriate search keys and indexes, based on the content of the data and automatically initiate the remote search on the preferred Z3950 targets.
How the remote databases should be searched is defined from AFO822 – ILL Departments – Z3950 Searching.
The first three fields (Search string, type, and profile) define the search to be made, based initially on the selected key as above.
The second part of the screen shows up to 10 matches at a time. Author, title, the source of the data and summary holdings for the remote service are displayed. (Clearly, what is available for display depends on the source being searched).
: Displays the MARC record for the selected line.
: This pulls the selected record back into the request. If the target is linked to a ILL library code, then this is added to the request as the proposed supplier of the requested item.
and : Retrieves the next set of records for the current search (or steps back to the previous set).
: If the search term generated from the request source details fails to find a useful match, then any of the Search term, Index or Target profiles may be changed and a search retried.
In the above example, the original request was
And after selection of the catalogue record for Montreal Uni, the “Bibliographic” tab is now populated as
The system has pulled a copy of the bibliographic record back into the Request database which, when viewed from AFO 111, looks like
: Allows staff to place a reservation for the selected title. This simply creates a "regular" reservation for the request. The incoming request has been accepted (will supply) by the ILL department, an appropriate local bibliographic record determined, and now the department wishes to either place a reservation on the title (e.g. if all copies are on loan) or simply to place a reservation, such that the usual internal library mechanisms are "invoked" to get the book to the ILL department.
The system takes the user to the reservations processing (e.g. AFO 421) as if the title and borrower had been identified – that is the user is taken to this screen:
As you can see the ILL department is actually the “borrower”.
From here, the reservation process can be cancelled or specific copies as required (in the usual way) can be selected.
The pickup location would, of course, default to the ILL Department, but it need not be so (for example, it might be policy for circulation staff to simply hold the item at the main reservation desk, and leave ILL staff to go and collect the item, when notified according to the "message by" settings.
It is also possible to send a Request reply to the requesting library.
Whether this is required depends on whether the reservation was placed because there really were no available copies OR whether this was just to use regular workflows in the library to get a copy of the title to the ILL department. In the latter case, presumably a “Hold placed” answer wouldn't be appropriate.
Subsequently, appropriate items would appear in the Picklists, Reservations messaging, be trapped on return in AFO 412 and so on, in the regular way.
: This allows “control” of the request to be transferred to another ILL department. When a client (borrower) enters a request from the WebOpac, then their home location is used to ascertain the ILL department to use (or there is an option to allow them to choose) – but it may be more appropriate to allow the request to be dealt with by another department (particularly for Document Delivery requests).
The dropdown list shows departments as defined in AFO 822.
: Takes staff to the screens for maintaining libraries to which requests might be forwarded. It actually does two things – it lets staff maintain the "send-to" list, and to initiate the forwarding of a request to a library on that list.
You can use the Forward command, or check the Forward option when recording the "not supplied/cancelled" action:
If the state of the request is currently "Not supplied", then the following form is opened.
As can be readily seen this is almost identical to the Supplier tab on the main request screen. If a "send-to" list has been defined already, then the system will populate these fields with the details from the next entry in the list. It can be seen that the Libraries tried and Forward to boxes are appropriately updated.
Most of these fields are (at least, in principle) dependent on the library supplying the item, but Service type, level, form, medium, maximum price, will pay fee are retained from their previous values. Reference number, search level and other instructions etc are cleared.
At any point, the "" button may be used to amend the "send-to" list. If the option to forward the request was taken (when the "not supplied" action was taken) and NO previously set Forwarding details are defined, then this screen is offered as "blank".
At this point, the system will allow any library to be selected here – it does not need to be on the send-to list already, you can add one.
In all other cases, the user is taken to the "Maintain" function automatically.
The first point to note is that the send-to list may be (semi-) automatically populated by doing a Remote Search as described under searching for bibliographic information. (In brief, it is possible to search remote libraries for a matching title using Z3950, and then if selected the library code may be added to the send-to list).
The maintenance screen lists the libraries to which the item is to be forwarded:
The system shows a border with those libraries already tried, for the sake of completeness. This is followed by a listing of the libraries in the send to list. This includes the currently selected library.
: Use this option to add a new library to the list. The system will prompt for a supplier:
: Select a line and then this option to remove a library (subject to being in process, of course). The system does NOT prompt for confirmation.
: Use this option to re-order the preferred sequence of forwarding.
So long as the first library is not in process, the Move command can be used to replace the existing selected supplier by the selected one. The system will prompt for the line before which the item is to be moved.
: This offers an option to convert the outgoing ILL request to an order (instead of requesting it from another library) or, if the work requested is actually held by the library, then the request may be 'changed' to a regular reservation.
Since this may require further approval, the request is actually copied to a standard "potential orders" list. (This is documented elsewhere). After selecting the option, a message will be displayed:
After clicking , another message will be displayed:
The title has now been added to the specified potentials file:
(The above screen is for illustration only. The name of the list will be defined for the ILL department, with a date suffix in the form DDMMYYYY to make each list unique).
The lists will be created on a daily basis – that is, such requests are grouped together on a daily basis, for subsequent processing.
At this stage, the request will be retained as such, but displayed to the client with an appropriate status, such as "This title may be ordered by library".
At the point that the potential record is actually converted to a real order, then the request is converted to a regular (on-order) reservation, and the client notified.
If the potential request is cancelled, then the ILL request is given an alert status so that it can be reconsidered by ILL staff.
If a Search has been made on the request and a local catalogue record assigned, then the Change command leads to the following prompt
The precise screen depends on the options in use in the system.
If a reservation is requested, then a reservation is created for the client and the request marked as “Changed to a reservation”, and appears in the “Completed” list.
A notice to the borrower to inform them that the request has been changed to a reservation is generated.
Note
The command button is also available on the form when you manually input a new incoming request. In that case there will be an automatic change to a document delivery request. A message to that effect is displayed:
: Takes staff to the "complex" charges maintenance screens.
These are calculated automatically for
· The charge made to supply an item for an incoming request
· The charge made to a client for an outgoing request
· The expected charge made to the library for an outgoing request
These are based on the schemes defined in AFO 822 – ILL Charge schemes (see the help of that AFO for more information).
These are initially calculated as “provisional” e.g.
for an incoming request, and an identical display for outgoing requests.
for the charge made to the client.
The charge to a client is always in the local currency of the system, but may be calculated in any currency for library charges.
The button takes the user to a more detailed screen to show the charges, and the specific amounts may be manually updated or recalculated on the basis of (for example) whether the charge is made to a budget or if the number of chargeable units affect the cost.
This shows the specific details, initially based on the charge scheme, but which may be updated manually.
Use the button to recalculate the total – so for example if the chargeable units are updated here, the button will recalculate the total.
A manually added “Additional charge” may be entered over and above any amounts in the charge scheme; a Note is mandatory for this.
The button allows the user to start again.
Once charges are entered here or the button is clicked, then the charge is no longer “provisional” and it will appear as [23.40]” i.e. in square brackets in the main displays. This does NOT mean that it is necessarily payable – the “Create invoice for charge” option must be checked to make it appear on an invoice.
The Charges display will then show
It shows as “Billed” to indicate that it has been made payable but the Invoice number will only appear when the invoice generation is run.
The Charges may always be updated – in which case a second invoice (if necessary) will be generated.
It is not possible to amend the charges once billed such that the total would be reduced
The charges command for outgoing requests leads to a form which allows for two similar sets – one for the charges to the library and of course another for charges to the client (borrower).
This shows the specific details, initially based on the charge scheme, but which may be updated manually.
In this case, there is no provision for generating an invoice, but an invoice number (or numbers) can be recorded against the request.
The system uses the charge calculation schemes to determine a charge, but of course ultimately this is determined by the supplying library. It is therefore not necessary to setup charge schemes for this purpose, but it may be useful for budgetary control. The calculations here are available for reporting purposes (e.g. SSP for example).
Often the accounting for the charges made by supplying libraries would be managed by systems external to the ILL module.
The button takes the user to the calculations for the client.
The dropdown list will display any budgets linked to the borrower record.
Use the button to recalculate the total – so for example if the chargeable units are updated here, the button will recalculate the total.
A manually added “Additional charge” may be entered over and above any amounts in the charge scheme; a note about this must always be entered. A Note is mandatory for this.
The button allows the user to start again.
The Admin fee ( a fixed charge) is shown here – but since this is calculated when the request is placed, it may not be amended.
When you check the option Make request charge payable, then the charge is allocated to the borrower record; or, if chargeable to a budget, then an invoice for the budget (or department linked to the budget) will be generated.
The button returns the user to the library charges screen.
When charges become payable is determined by parameters in AFO 822 - General system settings.
Note
The charges screens are also available at point of supply.
Some libraries offer additional instructions, which may be chargeable. This is defined in AFO 822 – ILL Libraries – Other instructions.
For example
If he additional charge is added manually, then the charge arising from other instructions is not reapplied.
Some care is needed with the currency – it is assumed that the amount entered against the other instruction is in the same currency as that shown in the charges fields.
: Causes a display of the states and events during the life of the request.
The history kept for a request is NOT a full transaction log of each and every change made to the request. Rather it is a history of the actions and events initiated by the Actions/Events commands – it is a history of its interaction with responding libraries.
The only other changes explicitly logged are the change of client (for an outgoing request) or the change of local bibliographic record (for an incoming request.)
In addition, a full history of notices sent for the request is kept.
The History command gives a simple listing in reverse chronological order of the actions for the request. These include both manual and ISOILL originated actions.
For outgoing requests, the history will include only the "current" responding library's transactions. An indication of the existence of other, presumably failed, transactions, will be shown, and an option exists to select other sets of historic transactions.
For ISOILL transactions, specific "internal" control information may be displayed. For the most part, the display of data is clearly much the same data as was used to create the actions in the first place – in other words, the display of a cancellation message will obviously show the information that was entered to create the message!
A few examples of the detailed displays follow
This is the history of a received request. In this case, there are two additional functions which can be used.
a. Various settings may be updated from this display – for example, if the user chose not to make the received item available to the client, then it can be made available from this display, or the actual location of an electronic copy (e.g. a PDF file) can be entered here.
b. “” allows the user to display the actual electronic copy.
The following is an example of the display of a “condition” added to the request
Note in this example that the button is available for this specific event.
So for certain displays an additional command button allows for an immediate reply to be entered or action to be taken, unless the status of the request is such as to make this inappropriate. (This could also be achieved by exiting the function and returning to the request and then using the Action/Event command, but the specific button is a shortcut).
: Is used to actually SEND the outgoing request. Dependent on whether this is to an ISOILL library, a dialogue is opened regarding printing and so on. (This is really an Action/Event as well, but is a shorthand command to get to this action).
The command is used to send the request itself and / or send a general message to the supplier:
N.B. Other instructions : If "other instructions" are added to a request, then at the time of sending the request, the system will check whether this is normally an ISOILL request. If it is, then staff have an opportunity to send the request as if it were a non-ISOILL library; thereafter all subsequent processing is either as ISOILL or manual.
In particular, the option may be used to print a Copyright declaration notice. This may be printed there and then, or may be emailed to the client for them to print and sign. You can also do this later, after the original request has already been sent:
The command button for an incoming request offers the option to send a general message
: This is a short cut to take the user to the library maintenance screens, for the current responder (either the requesting or supplying library). This allows staff to make changes necessary for the correct processing of the current request without having to exit the request, go to the library maintenance routines and back again!
See the help of AFO 822 – ILL Libraries for a description of this screen and its options.
: This lets you search for a client for the outgoing request if not entered. If a borrower has already been entered to the request, then the Borrower command takes you to the regular borrower display (as in AFO 431).
If you need to change the requesting borrower, you must use the button first to remove the current details. Then you can use the button to search for the correct borrower.
The requests status field on the request form is for display purposes only. It shows the current status of the request and then additional information depending on the status - for example, it will show the Due date, whether the borrower has requested a renewal.
The separate elements of a status are shown on separate lines.
The Alerts field may give more information related to the status.
Examples:
Listed under Pending
Listed under Conditional
Listed under Cancel required
Listed under Supplied
Listed under Overdue
Listed under Total rejected
Examples:
Listed under Pending
Listed under In process
Listed under Conditional
Listed under Received
Listed under On loan
Listed under To be returned
Listed under Total completed
Any prints NOT printed immediately are put into a “deferred print” queue. Similarly outputs generated by “overnight” processing e.g. overdues are also generated automatically but then queued up for physical printing.
After selecting this menu option, an overview screen will be displayed:
Here we can see a variety of different outputs waiting to be printed, with an indication of the volumes of output concerned.
: Select a line and then this option to view the requests in the particular print job. See section 821.8.1.
: Select a line and then this option to send the outputs for the selected line to the printer (or to be sent by email). The standard screen for generating mailmerge output will be displayed.
: This option allows you to retrieve results from previous dates. See section 821.8.2.
: Select a line and then this option to view the requests in the particular print job. A summary screen will be displayed:
: Select a line and then this option to send the outputs for the selected line to the printer (or to be sent by email). The standard screen for generating mailmerge output will be displayed.
: Select a line and then this option to delete the print from the summary. The system will prompt for confirmation.
: Use this option to send all outputs to the printer (or to be sent by email). The standard screen for generating mailmerge output will be displayed.
: This option allows you to retrieve results from previous dates. A summary screen will be displayed:
: Select a line and then this option to view the requests in the particular print job.
: Select a line and then this option to delete the historical print list from the summary. The system will prompt for confirmation.
This function may be used to both test that the ISOILL configuration is working and allows some simple messages to be sent backwards and forwards to allow for training of the use of ISOILL in the system.
The test function allows you to send a request, and subsequent dialogue, to a library added to the system as “INFOR:TEST”. It is also possible to send requests FROM INFOR:TEST to the ILL department, thus allowing for training of how these messages are seen.
Such requests are sent via the full protocol i.e. are sent out of the system (and back in again) via the full email server, and therefore provide a good test of the system, and particularly that the configuration is working.
The actual configuration is done by creating a special test library in
AFO 822. Please contact the helpdesk for more information on setting this up.
The interlibrary loan module provides support for the document delivery function. This process sits somewhere between the management of incoming requests and outgoing requests. For document delivery we are concerned with the supply of library material externally to library users – typically corporate organizations e.g. when the library supplies material to, say, a law firm.
This is often managed by an interlibrary loan department, and so falls into the general management functions of interlibrary loan.
It is similar to an incoming request
· The request is for the supply of a loan or a copy of a work or article from the library's holdings.
· It is necessary to ship the material either by mail or some kind of delivery service, or to send a copy electronically, perhaps of a single article of a journal.
· The material is returned in the same way i.e. not returned by the borrower in person to the library.
· Payment for the request is typically managed by invoice, externally from the main circulation system
It is similar to an outgoing request
· The supply is to a member of the library
Although a regular issue of the title to the borrower might handle the basic functions, it does not support the supply of a copy of a work; nor is there a mechanism in the more traditional circulation functions to allow the system to record the full details of the request, the fact that a copy rather than a loan is required and so on.
There is a parameter in AFO 822 – General options – General system settings, which determines whether document delivery is in use.
In AFO 822 – Document delivery options, you can specify the borrower categories that are allowed to request loans and / or copies.
Requests can be entered as document delivery requests on the staff side (and other ways are described below). In particular it is possible to offer this function to specific categories of borrower from the WebOpac.
Borrowers can place document delivery requests via the WebOpac (dependant on parameters as described above). Such requests appear in the “Incoming” section of AFO 821, since they have most in common with regular incoming requests (In most circumstance, the requester can be considered as an external library).
In the column “Library” you will see “Document delivery” instead of a library name.
The request displayed is almost the same as for an incoming request, but the “Requester” tab is replaced by the “Client” tab from an outgoing request.
This is almost identical to that for an outgoing request but it should be noted that some of the settings which would have been logged against the requesting library are now on the client tab – specifically, the Service type and Service level.
When adding a new incoming request, it may be changed to a document delivery request by using the command.
This prompts for a confirmation:
This may only be used when the request is being created initially; once added an incoming request may NOT be changed.
If an outgoing request has been entered – for example, typically from the WebOpac, then it may be that it is determined that this is for material which the library holds.
As documented above it is possible to change this request to a regular reservation; however for the borrower categories for which this is permissible, it may ALSO be changed to a document delivery request.
Effectively, the processing of the request continues as for an outgoing request, i.e. it is FOR one of the library's borrowers. But it may be changed to a document delivery, which then affects the various options relevant.
The various commands available for a document delivery request are more or less the same as for an outgoing request (as if it had already been received). So for example, the “” option is never offered – this makes no sense. Similarly the “” option never appears – when the item is returned by the borrower then this completes the request.
Similarly, fields such as the Delivery address no longer appear for a supplying library but are rather taken from the borrower's circulation record.
· Document control - Change History
|
Version |
Date |
Change description |
Author |
|
1.0 |
October 2010 |
new AFO |
|